Support confirmed that the failures were caused by entering the user's email address instead of the local macOS account name (format: firstname.lastname) at the login prompt. In each incident users were able to sign in and regain normal desktop access after replacing the email with the local username and using their existing password. This applied both at regular logins and at the intro/login screen after initial setup or restart.

Temporary local-administrator elevation granted from the campus Self Service / Admin Minion (a 30-minute admin grant) resolved the reported macOS authorization failures in most cases. Elevation allowed users to authenticate with their local macOS account at system authorization dialogs and thereby install system and security updates, complete macOS upgrades, enable Screen Recording/Screen Sharing for Microsoft Teams, accept the Xcode license, move/install applications needed for Git/Unreal workflows, and finish related Git operations. Where the Self Service/Minion UI was stalled (endless spinner or a Run button that started then aborted), a restart commonly restored the Minion icon or cleared the stalled UI and allowed elevation to proceed; some stuck upgrades also completed during restart. Environmental diagnostics showed that institutional/SSO (Okta) credentials were frequently rejected by macOS authorization dialogs and the local account password was required, and that biometric authentication (Touch ID/Face ID) sometimes interfered with accepting password prompts. Jamf-delivered updates failed to apply on devices that had been offline, and devices that had not checked in to Jamf for long periods (examples around a year) prevented the 'Make me Admin' / 30-minute-admin app from granting elevation; such devices required re-enrollment or further IT remediation beyond temporary elevation. Misprovisioned devices (FileVault disabled, extra local accounts, incorrect device classification) occasionally required reimaging or deeper remediation. In at least one case application-level functionality (Microsoft Teams desktop) failed to open or send files and in-app apps would not launch; reinstalling the desktop client and logging out/in did not resolve that failure and Windows-specific cache-clean instructions were inapplicable, indicating that some app-specific problems were outside the scope of admin elevation and needed separate application troubleshooting or provisioning fixes.

Two distinct issue types were observed and resolved. Jamf Connect authentication errors were cleared by re-authenticating via the Jamf Connect menu-bar Connect option, which removed the incorrect-JAMF-login state. Persistent Keychain password-mismatch prompts that followed the macOS Tahoe 26.1 upgrade were resolved by resetting the user Keychain (removing items under ~/Library/Keychains) and rebooting; after the reboot users re‑authenticated to applications and Self Service+ and the prompts stopped. Separately, some devices lacked the IU Self Service app or could not find it in Jamf; in those cases device re-enrollment or reinstalling the IU Self Service package restored the app. One reinitialization case produced a macOS login failure that was resolved by resetting the user’s account password, after which Self Service access was restored.

Support traced the recurring "... damaged your computer" dialogs to a mismatch between macOS security assessment and the installed device-management/management-package (certificate or script metadata) for management scripts. The condition was cleared when management deployed the updated package: in some cases Jamf Self Service was used and an 'Update Inventory' action forced redeployment of the corrected management package, and in other cases a restart allowed the device-management system to receive and apply updated packages. After the updated management package was installed the security dialogs stopped. Affected scripts were commonly found in /Library/Management/Scripts and included ProtectAdminGroup.sh, ProtectSudoersFile.sh, and ProtectRootAccount.sh; dialogs frequently recurred every 1–3 minutes and could be non‑dismissible until package deployment completed.

In one incident the installer was cancelled using the application's 'Abbrechen' (Cancel) control and the Mac was restarted; an initial restart produced an unrelated window and a second restart returned the system to normal. In another incident a remote support session was established via TeamViewer Quick Support; the technician inspected the system, installed pending updates, and the subsequent restart completed successfully. In both cases the visible installer dialog blocked shutdown/restart and could not be terminated by Force Quit, and resolution required either cancelling the installer and rebooting or completing the pending installations before restarting.

Support retrieved the device's FileVault recovery key using the Mac serial number and provided the recovery code to the user (delivered by email). Where the recovery key unlocked the disk, the user entered it to unlock the startup disk or finish the macOS reinstall, which restored login access and access to files and applications. Apple Support had confirmed the system was requiring the recovery key before IT retrieved the key from management records. In incidents where the supplied recovery key failed with the error 'The supplied password failed to unlock the disk', or where the Erase Assistant required local administrator credentials the user did not have, on‑site IT performed a full macOS reinstallation from the machine; the local reinstall restored a working system and local administrator access.

IT confirmed that Time Machine backups were not permitted on IU-managed MacBooks. No supported workaround to enable Time Machine on the managed devices was provided.

The Tahoe 26.0.1 update was re-applied (the macOS update was installed again). After re-installing the update the performance and UI responsiveness returned to normal.

Support confirmed that Power BI Desktop was not compatible with macOS and that the installer would not run on a Mac. The user was directed to access Power BI through office.com → All Apps (Power BI web/service) for full browser-based reporting and to rely on the online Power BI service where desktop-only features were not available on Mac.

Support determined the Apple ID sign-up failed because the @iu.org address was not accepted by Apple's account creation flow. The user was advised to create the Apple ID using an alternative, non-@iu.org email address and to complete the normal verification step sent to that alternate email.

Technicians resolved the sign-in failures by resetting the local account password. In one case the Mac was booted into macOS Recovery Mode and the local account password was reset there; in another case the recovery key was used to reset the local account password. After the password resets the users were able to sign in normally.

Investigation found macOS Do Not Disturb (Focus) mode was enabled. Disabling Do Not Disturb on the Mac restored Teams, Outlook, and system notification sounds.

Support instructed the user to install macOS updates (Settings → General → Software Update) and recommended moving the device to a supported macOS release so Teams would continue to run. Guidance included updating the out-of-date installations and addressing device provisioning issues to restore normal Teams operation.

An infrastructure rollout was executed to bring iMacs to macOS Sonoma 14.5 by the required deadline. Targeted devices at Augsburg, Nürnberg, Würzburg, Frankfurt, Mainz, Essen, Bochum, Düsseldorf, Köln, Hannover, Braunschweig, Dortmund, Duisburg, Bielefeld, Bremen, Berlin, Dresden, Karlsruhe, Leipzig and Lübeck were updated to Sonoma 14.5 and marked Done. For remotely pushed updates that remained in an MDM/remote-push Pending state, the affected devices were monitored until the MDM status transitioned to Done and the upgrades completed successfully. Example device serials confirmed updated included C02J21NAQ6W1, H12GHHKWQ6X2, C02J2205Q6W1 and C02J22XZQ6W1.

The MacBook's keyboard input source was changed in System Settings to the German layout so the built-in and external keyboards produced matching German input. The change was confirmed completed.

The Jabra Direct application was uninstalled with admin rights and then reinstalled through the Jamf Self Service portal; this resolved the failure-to-launch symptom for the affected user. If reinstall via Self Service did not resolve the issue, the ticket instructed escalation to support for further investigation.

A support administrator recommended performing the upgrade over a wired LAN connection instead of Wi‑Fi and cautioned that the installer’s remaining-time estimate can be much shorter than the actual time required. The user retried the update multiple times with local administrator rights; the ticket was closed with no independent confirmation or error code documented that proved the network change definitively resolved the aborts.